chore!: remove npm shrinkwrap, use exact dependency versions#1121
chore!: remove npm shrinkwrap, use exact dependency versions#1121Renegade334 wants to merge 2 commits into
Conversation
1025adf to
c71756e
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1121 +/- ##
=======================================
Coverage 63.27% 63.27%
=======================================
Files 50 50
Lines 8342 8342
=======================================
Hits 5278 5278
Misses 3064 3064 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
c395aca to
9030665
Compare
That's not true, as you said after it only works for shallow deps. I'd rather just rename the file to |
|
Any votes for |
|
Do we have some figures on how big of a bundle we're talking about? |
This wouldn't work for installing NCU globally, the idea is to pin the entire dependency tree when installing it globally (to prevent supply chain risks in transitive deps). |
Looks like we would need to first upgrade c8 to eliminate the After doing so, npm is reporting a packed size of 120KiB for the conventional package, and 8MiB for the bundle, including 355 transitive dependencies. It won't make a difference for a first install, since all of those would need to be fetched anyway, but it will potentially make upgrades slightly slower (as the whole bundle will need to be fetched, even if dependencies aren't changing), and will impact upon npm dependency deduping, although this shouldn't matter too much for a global install. |
3 participants
Resolves #1078.
We are currently locking consumers' dependency versions by using npm-shrinkwrap.json, which causes npm to lock the dependency tree to the npm-shrinkwrap.json versions when resolving.
We can achieve a similar effect by de-ranging the dependency versions. We weren't actually allowing npm to "choose" a dependency within these semver ranges anyway, because npm-shrinkwrap.json existed.
This approach wouldn't guarantee strict versioning of dependencies-of-dependencies for packages which specify version ranges for their own deps. The alternative would be
bundleDependenciesto basically ship a pre-packed node_modules, which would also give some version control over transitive dependencies, at the expense of quite a bulky package.Either way, it'll be technically breaking because node-core-utils is now subject to external npm
overrides, which shrinkwrap disallowed.